home *** CD-ROM | disk | FTP | other *** search
/ CU Amiga Super CD-ROM 17 / CU Amiga Magazine's Super CD-ROM 17 (1997)(EMAP Images)(GB)[!][issue 1997-12].iso / CUCD / Programming / AMOSList / AMOSLIST.0997 / 000161_amos-request@svcs1.digex.net_Wed Sep 17 21:35:49 1997.msg < prev    next >
Text File  |  1997-10-01  |  3KB  |  68 lines
  1. Received: from svcs1.digex.net (svcs1.digex.net [204.91.197.224])
  2.     by mail2.access.digex.net (8.8.5/8.8.5) with ESMTP id VAA10422
  3.     for <mcox@access.digex.net>; Wed, 17 Sep 1997 21:35:46 -0400 (EDT)
  4. Received: (from daemon@localhost)
  5.     by svcs1.digex.net (8.8.5/8.8.5) id UAA26396
  6.     for amos-out; Wed, 17 Sep 1997 20:29:12 -0400 (EDT)
  7. Received: from mail4.access.digex.net (mail4.access.digex.net [205.197.247.2])
  8.     by svcs1.digex.net (8.8.5/8.8.5) with ESMTP id UAA26393
  9.     for <amos-list@svcs1.digex.net>; Wed, 17 Sep 1997 20:29:11 -0400 (EDT)
  10. Received: from m6.sprynet.com (m6.sprynet.com [165.121.2.89])
  11.     by mail4.access.digex.net (8.8.5/8.8.5) with SMTP id UAA24612
  12.     for <amos-list@access.digex.net>; Wed, 17 Sep 1997 20:29:10 -0400 (EDT)
  13. Received: from sprynet.com (ragriffi@ad82-023.compuserve.com [199.174.203.23]) by m6.sprynet.com (8.6.12/8.6.12) with SMTP id RAA05631 for <amos-list@access.digex.net>; Wed, 17 Sep 1997 17:29:05 -0700
  14. From: Richard Griffith <ragriffi@sprynet.com>
  15. Reply-To: Richard Griffith <ragriffi@sprynet.com>
  16. To: AMOS mailing list <amos-list@access.digex.net>
  17. Date: Wed, 17 Sep 1997 20:18:51 +0500
  18. Message-ID: <yam7199.2582.118951648@m6.sprynet.com>
  19. In-Reply-To: <yam7198.787.3595520@mail.redrose.net>
  20. X-Mailer: YAM 1.3.4 [040] - Amiga Mailer by Marcel Beck
  21. Subject: Re: TextEditors..
  22. MIME-Version: 1.0
  23. Content-Type: text/plain
  24. Status: O
  25. X-Status: 
  26.  
  27. Jens Vang Petersen asked:
  28.  
  29. > now I'm wondering, how a fast editor like 'GoldED' or 'McEmacs' is working
  30. > when one's just typing ahead, does it simply reserves an amount of memory
  31. > and then when I enter a new letter (Inserting) it simply moves the text
  32. > after the  new character a place ...
  33.  
  34. The micro-emacs strategy, at least in the flavors I studied, had
  35. a line structure like:
  36.   - list link (pointer to next line)
  37.   - allocated size (how much memory allocated for this line)
  38.   - actual size (how much used for this line)
  39.   - buffer pointer (to the line data)
  40.  
  41. The memory allocated was based on the expected growth of the
  42. line. A line read from a file was given just enough allocation
  43. to hold it (not growing). Then when edited the line allocation
  44. would be increased to a multiple of a preset block size. An
  45. insert or delete of a character would indeed 'copy' the rest
  46. of the line's data to new positions in the buffer.
  47.  
  48. Anyway, the allocation scheme isn't really where the 'speed'
  49. comes from. (Good thing, too, as I would expect that to be
  50. a nightmare to try and mimic in Amos. Probably easier to
  51. allocate for a very big line, and leave it.) Speed is judged
  52. by the response time the user sees, and the slowest part is
  53. actually putting the characters on the screen. There are
  54. many ways to do this (many Memacs variations had a 'cost'
  55. table, where several ways to refresh the screen would each
  56. be 'scored' for cost, and the strategy with the lowest score
  57. was used to paint the screen. Definite overkill for your
  58. case.) 
  59.  
  60. The core of the strategy always came down to update as little
  61. as possible, and the most common case was erase from cursor
  62. to end of line and reprint what should be there. That should
  63. be a lot more practical.
  64.  
  65. Hope this helps,
  66. -Richard
  67.  
  68.